home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / RE>Re ODF Clock < prev    next >
Encoding:
Internet Message Format  |  1996-07-15  |  2.7 KB  |  [TEXT/ttxt]

  1. Subject:     RE>Re: ODF Clock
  2. Sent:        7/12/96 1:43 PM
  3. Received:    7/12/96 1:56 PM
  4. From:        Rob Cope, rob@eclipse.cpcn.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.  
  9.                                                                  Date: 7/9/96
  10. Subject:  RE>Re: ODF Clock                                      Time:  4:41 PM
  11. I sent this a few days ago, but never saw it come back from the list.  Sorry if it is duplicate.
  12.  
  13. -----------------------------------------------------
  14.  
  15. >Are you sure you are creating the embedded frame with an ODShape zero 
  16. >based (top left corner of the bounding box should be (0,0))?
  17.  
  18. Yes, I am using the same code as ODFContainer.
  19.  
  20. >>All the sample ODF parts 
  21. >>(Draw, Container, Embed) do end up calling ChangeFrameShapes as a side 
  22. >>effect of how they work.
  23.  
  24. >I tried reproducing your problem with ODFDraw (ODF 2 version but it 
  25. >should be the same as ODF 1) and it doesn't call 
  26. >FW_MProxy::ChangeFrameShapes when a stationery is dragged in or when  
  27. >a document is opened with embedded frames. 
  28.  
  29. When ODFContainer's SingleEmbeddedFrameInteralized is called, it sets the frameLoc to the middle of the contentView.  Facets are then created.  Next, the DropCommand offsets the part to the location of the mouse where the drop occurred.  The offset code calls the proxy's ChangeFrameShape.   Set a breakpoint in FW_MProxy::ChangeFrameShapes to see the details.   ODFDraw works the same way.  A similar process happens in the Insert command.
  30.  
  31. I have figured out the root my problem, however.  The ODFClock sets the bounds of its used shape such that the used shape does not start at (0,0) within the frame (which is perfectly legal).  I have code in UsedShapeChanged that sets the embedded part's external transforms such that the top left of the part's used shape is always in the same position as the top left of the facet I create for it. This is necessary given the nature of the way my part handles layout (an outline).  
  32.  
  33. This scheme works just fine except for in 1 case -- when the part changes its used shape right when I create a new facet for it.  At that point, my call to ChangeExternalTransforms in UsedShapeChanged has no effect.  I'm not sure why that is, but it is true for every part, not just the clock.  My current hunch is that it is because the embedded frame's FacetAdded has not been called yet, but that's just a guess.  My workaround is to make sure I always call ChangeExternalTransforms after the process of creating the facets is complete.
  34.  
  35. Any ideas about why the call to ChangeExternalTransforms in UsedShapeChanged doesn't work when creating a facet?
  36.  
  37. Thanks,
  38.  
  39. Rob Cope
  40. Eclipse Services
  41.  
  42.  
  43.